Conversation
| const size_t suffix_len = 6; // Length of "XXXXXX" | ||
|
|
||
| // Create a modifiable copy of argv0 | ||
| char argv0_copy[PATH_MAX]; // Ensure this is large enough for your use case |
There was a problem hiding this comment.
Please stop using PATH_MAX! Not only me but others have told you more than once that this variable's name is really misleading. One can allocate the buffer to the correct size directly in this case. (Or just use C++...)
There was a problem hiding this comment.
See, e.g., #38, which attempts to fix some of this mess...
There was a problem hiding this comment.
Point taken, but at least with this change we don't get an immediate segfault like we had before.
(This whole world of pointers and buffers is not what I normally want to deal with. But here in the runtime we currently have to use C indeed at the moment.)
There was a problem hiding this comment.
The runtime really needs way more love to fix some of those C-isms. I wish C had a real string concept. But then again, we wanted to rewrite the runtime in another language anyway. The main issue with that is that libfuse is not available for languages like Rust, at least nothing that would be maintained or remotely up to date. Languages like Go don't fix the real issues we have either. C++ would fix most of the complaints but including the STL causes the binary to grow size wise.
There was a problem hiding this comment.
Indeed. So C it is. Just needs some love.
There was a problem hiding this comment.
Well, I have some hope for Rust using FFI. That'd still eliminate most of the issues on our side.
There was a problem hiding this comment.
Will asprintf() help in that case?
Also things like strlcpy() are currently
available in glibc.
Just my 2 cents.
3 participants
This seems to fix
@TheAssassin I am going to merge this as an emergency fix (since the runtime segfaults without this, this won't make it worse), please do carefully review afterwards nonetheless. Thanks!